Conventionally, devices were polled to determine a particular state. Today, however (in lieu of polling) interrupts are widely employed for hardware devices to notify processor(s) that attention is needed. For example, an interrupt can convey state of a device such as, a request is complete or a configuration has changed (e.g., cord pulled out). Generally, once an interrupt occurs, an operating system analyzes the state of the device and performs an action in accordance with the interrupt—this is in lieu of polling the device.
Interrupts are asynchronous external events to the processor that can alter normal program flow. They usually require immediate attention from the processor. Interrupts are very important for high speed input/output (IO) processing because they free up resources. When an interrupt is detected, the system often interrupts all processing to attend to the interrupt. In accordance thereto, the system saves the state of the processor and instruction pointers on the stack. An interrupt dispatch table in memory can be accessed by the processor to identify a function that is to be called in response to a particular interrupt. For example, a function can clear the interrupt for a variety of reasons. The function can execute processes such as clearing the state of the interrupt, calling a driver function to check the state of a card and clearing, setting a bit, etc.
The interrupt call can perform a small amount of processing on the controller and then return to the processor by obtaining the state from the stack and resetting the system to a state prior to the interrupt. In other words, the code that was running prior to detection of an interrupt stops executing in order to permit the interrupt to perform a specific function and then restarts where it halted once the function is complete.
It will be appreciated that, if a driver crashes, the failure is recorded as a kernel level fault and the system crashes. If a crash or failure occurs, the system memory and processor memory can be corrupted. Therefore, designers have been seeking alternative schemes to take existing systems for drivers and have them run in a user mode process. Recent developments have been directed to the use of driver isolation methods. However, a problem in terms of handling driver isolation is that interrupts are typically entirely associated with the operating system kernel. In other words, traditionally, user mode processes do not see interrupts. Unfortunately, in a driver isolated environment, the drivers run in a user mode process which requires delivery of the interrupts thereto.
What is needed is a system and/or methodology to get these kernel level interrupts (which can have many restrictions associated therewith) to the drivers in a user mode process. This is particularly difficult because the drivers in a user mode process are expecting to run only when there are no interrupts in operation. In other words, an issue with isolating device drivers is how to make device interrupts available in the driver protection domain. Some types of interrupts can simply be deferred, but for others the operating system must invoke the driver to clear the interrupting condition before the machine can return to normal functioning. Accordingly, a substantial need exists for a system and/or methodology that facilitates delivering interrupts into a process-based protection domain. This delivery into the user mode process would permit isolated device drivers to be compatible with respect to a wider variety of hardware.